Analysis and Solutions of Common Causes of Serial Port Lost Data

UART stands for Universal Asynchronous Receiver/Transmitter, also known as what we often refer to as a serial port.

One of the serial peripherals that engineers utilize the most frequently is the serial port, but real-world applications frequently run into a variety of issues. One byte of data, for instance, is gone.

Today, we'll discuss STM32 and UART-related topics, as well as the issue of quickly losing one byte of data.

Ⅰ. UART several flags

Here, we'll concentrate on the TXE, TC, RXNE, and ORE flag bits found in the UART status register.

Figure. 1

Programmers frequently use these flag bits. These flag bits might not matter to students who only utilize the function library indirectly. Inadequate use of them could result in data loss.

TXE: Transmit data register empty

0: Data not transferred to shift register

1: Data transfer to shift register

TC: Transmission complete

0: Transmission not completed

1: Transmission completed

RXNE: Read data register not empty

0: No data received

1: Ready to read received data

ORE: Overrun error

0: no overflow error

1: An overflow error was detected

Ⅱ. UART communication hardware interface

Common UART communication hardware interfaces include: TTL, RS232, and RS485.

When programming, the communication interface technique must be taken into account. The line's latency needs to be taken into account while communicating across vast distances. Loss of data will also result from improper operation.

1. TTL

TTL is relatively simple, that is, it is directly connected to the Tx and Rx pins of the UART without external conversion. As shown in the figure:

Figure. 2

Note: Tx and Rx pins need to be cross connected.

2. RS232

One of the most widely used serial communication interface standards is the RS-232 standard interface, which specifies that the level of logic "1" is -5V to 15V and the level of logic "0" is +5V to 15V.

This electrical standard was chosen to expand communication range and enhance anti-interference performance.

Figure. 3

3. RS485

RS485 typically uses a two-wire wiring approach. There can be connections between several nodes on a single bus in this wiring topology.

Ordinary twisted pair cables can be used in low-speed, short-distance, interference-free situations; however, for high-speed, long-distance transmission, RS485 special cables with impedance matching (typically 120 ohms) are required. Armored twisted pair shielded cable should also be used.

Figure. 4

Ⅲ. UART receive lost data

The loss of data received by the UART may be related to both software and hardware. Here are some common causes and solutions for lost data.

1. Receive overflow lost data

refers to data loss as a result of an overflow error caused by a delay in taking data, which typically happens when a lot of data is received and data is obtained by a query. Too much data is collected and processed slowly during the MCU's initialization procedure, delaying the response of the complicated system. Loss of data will happen.

Solution:

Clear overflow error flag in time

Utilize communication protocols to filter problems caused by data loss

2. Receive interrupt lost data

The UART interrupt is more frequently used to receive data than to query that data. Although the interrupt method replies faster than the query method, it will still lose data if it is processed excessively.

When there is a lot of data, the UART receive interrupt function takes a long time, has a low priority, and it is simple to lose data.

Solution:

Reduce unnecessary time-consuming in the interrupt function

Reasonable allocation of interrupt priority

Clear flags before enabling interrupts

3. Clock errors lead to lost data

In the case of high communication baud rate, if the clock error increases, it is likely to cause data loss.

Solution:

Use a higher precision crystal

Decrease the communication baud rate

Ⅳ. UART sends lost data

Many engineers have experienced lost data transferred through UART, which is typically the cause of the transmission being incomplete.

Although the HAL library has been around for a while, many engineers continue to use the conventional peripheral library. The last byte of data delivered will be lost if the interface is not properly wrapped at this point.

1. UART transmission is not completed resulting in data loss

The following code only considers non-null, but the actual transmission is not completed.

void UART_SendByte(uint8_t Data)

{

while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TXE));

  USART_SendData(USART1, Data);

}

Sending non-null does not, however, indicate that the sending is finished. It will result in data loss in some circumstances, despite the fact that it is more effective in some.

Use this function, for instance, to put the receiving end device to sleep after transmission or to switch off the power.

Solution:

Wait for sending to complete:

void UART_SendByte(uint8_t Data)

{

while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TXE));

  USART_SendData(USART1, Data);

while(RESET == USART_GetFlagStatus(USART1, USART_FLAG_TC));

}

If you use the standard peripheral library, encapsulate the function according to the actual situation, such as sending timeout.

Or use the HAL-encapsulated interface, and the code includes judging that the transfer is complete:

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)

2. Line delay leads to data loss

UART often employs 232 or 485 to lengthen transmissions and boost interference. However, there will be a transmission delay once the data line is too lengthy, particularly when 485 transmits over a great distance and uses the MCU to control the transmission direction.

Solution:

Software adds delay processing

Use the communication protocol to increase the response mechanism

3. Other reasons

Numerous application cases exist for UART. Some of them are used in sophisticated factories where there is a lot of interference, which causes data loss; others are used in places with big temperature swings where there is a lot of clock offset, which causes data loss.

The remedy must be based on the actual circumstance and be directed towards fixing the issue. Use more reliable communication channels, for instance, or implement fault-tolerant processing in software, etc.